damn there's no config.h …

Thanks for working on this port — it is clearly a serious effort, and I appreciate the amount of research and implementation work that went into it.

That said, I am not in favor of merging this PR in its current form.

My main concern is not that MiNT is niche by itself, but that this adds a new long-term maintenance surface for a platform that the project is unlikely to have active maintainers, regular users, or any CI coverage for. In practice, that means:

• future changes to shared structs, module interfaces, or common helpers can silently break MiNT code,
• nobody may notice those regressions for a long time,
• and the burden eventually shifts to core maintainers who do not use or understand the platform.

This PR also does not stay fully isolated in platform-specific files. It modifies a fair amount of shared/common code to accommodate MiNT. That raises the maintenance cost for everyone, not just MiNT users. For a platform with no verification pipeline and uncertain long-term usage, that tradeoff seems hard to justify.

I am also uncomfortable with some of the compatibility techniques used here, especially changes like:

• replacing static_assert with an empty macro,
• redefining or bypassing low-level APIs just to force compilation,
• and more generally introducing compatibility paths that appear to hide unsupported behavior rather than model it cleanly.

Even if these choices are understandable for getting an initial port running, they are difficult to accept in core shared code because they reduce confidence in correctness and make the codebase harder to reason about.

So my current view is:

• As a proof of concept / external port: this is interesting and valuable.
• As mainline support in fastfetch: I do not think it is ready, and I am not convinced the long-term maintenance cost is worth it.

I would be more open to reconsidering this if the port could be reworked to:

1. keep almost all changes isolated to MiNT-specific files,
2. remove the more aggressive compatibility hacks from shared headers/common code,
3. document a realistic maintenance story,
4. and ideally provide at least some reproducible way to validate builds going forward.

Without that, I think merging this would likely create dead code over time rather than sustainable platform support.

I'll be busy the rest of the month, but I'll look into that. Some thing will be hard to do though, unless adding a statat syscall to MiNT… But maybe the usecase is simple enough it can be emulated. Some things might be better off with feature checks than ifdeffing on the OS.

Maybe some function should be moved to something the platform can override instead of the ifdeffery… Or platform-specific includes?

It should be possible to add proper CI since the cross tools are packaged for Debian, never did that on github so it's an occasion I guess. Might need to make a few gigs of space here though… Might even get ARAnyM with a headless console 🤔